store origin navState instead of G4TouchableHandle in HostTrackData#487
Merged
SeverinDiederichs merged 1 commit intoapt-sim:masterfrom Feb 19, 2026
Conversation
|
Can one of the admins verify this patch? |
2 tasks
2 tasks
JuanGonzalezCaminero
approved these changes
Feb 19, 2026
Contributor
JuanGonzalezCaminero
left a comment
JuanGonzalezCaminero
left a comment
There was a problem hiding this comment.
Thanks for the fix!
SeverinDiederichs
deleted the
store_originNavState_overTouchableHandle
branch
SeverinDiederichs
added a commit
that referenced
this pull request
Feb 20, 2026
Note: this PR depends on #487 and is therefore based on it, as otherwise merge conflicts would arise. Only to be reviewed after rebase when #487 is merged! This PR introduces a secondary vector in the G4Step. Thus, SD codes or UserActions that rely on the secondary vector will now not find only a secondary vector, but the correct secondaries produced in that step. After the reordering #486, this PR changes the following: - The steps on the GPU are now recorded [parent1][secondary1,1] - [parent2][secondary2,1][secondary2,2] - [parent3]... - the number of secondaries is returned in the step - When looping over the returned steps and processing them, the parent steps directly consume the corresponding secondary steps - The secondary steps are still just the initializing steps, so they setup the HostTrackData mapper. - Before, the secondaries always had to query for the hostTrackData entry of the parent to get the G4 parent ID. As they are processed now together, the G4 parent ID can be directly passed, which reduces the expensive lookup and therefore accelerates the code - Similarly as before, a persistent storage for the secondary tracks and also for the secondary vector is created, to avoid re-allocation. This made notable run time differences For turning the userActions on, this PR slightly improves the run times over #487: | Example | PR 487 | This PR | |---------------|--------------------------------|----------------------------| | Em3 Regions | 95.486 | 94.4245 | | Em3 | 116.413 | 110.233 | It was verified that this PR - [ ] Changes physics results - [x] Does not change physics results
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR fixes the origin Touchable handling in the HostTrackData Mapper.
Before, there was a
!missing in this if-Statement:Thus, the originTouchableHandle was never set. Fixing it, a major run time regression was found.
Indeed creating
G4TouchableHandleis very expensive.Therefore, now the
vecgeom::NavStateis stored in the hostTrackData and theG4TouchableHandleis only created when the track is returned to G4 from the GPU and not already per step.This mitigates the impact significantly. In the extreme case of testEm3 where each second layer is a GPU region, the overhead was drastically reduced, in normal cases it was fully mitigated.
As the origin Touchable so far is only needed by ATLAS, one might see if it should be guarded as a compile time option.
It was verified that this PR